In the computer systems architecture world, cloud computing has recently received some attention. Although there are many competing definitions for “cloud computing,” it generally involves (1) the delivery of computing as a service rather than a product, and (2) providing shared processing and/or storage resources, software, information, etc., to computers and other devices as an oftentimes metered service over a network (typically the Internet). In a cloud computing environment, end users do not necessarily need to know the physical location and configuration of the system that delivers the services. Applications typically are delivered to end-users as the service, enabling transparent access to the cloud-based resources.
More and more cloud drive providers (also sometimes called cloud store providers) are coming “online.” Cloud drives/cloud stores simply refer to hosted cloud content. While the proliferation of more providers is desirable for a number of reasons (related, for example, to the concomitant proliferation of different options and the services and features that each may provide), there is an emerging problem related to the ease with which a typical consumer or end user can manage his or her accounts. For instance, through natural use over time and/or interactions with others, an end user may need or end up with accounts with multiple cloud storage providers, potentially for the same (e.g., music, whether provided in MP3, MP4, or other format) or different types of media (including heterogeneous forms media such as, for example, eBooks, music, videos, personal photos, etc.)—and/or other information (such as, for example, personal computer data, back-up files, etc.). In this regard, a typical end user today might have to manage accounts associated with Apple iCloud, an Amazon Cloud Drive, Google Drive, Microsoft's SkyDrive, Dropbox, livedrive, Flickr, etc.
The end user might also be deliberately establishing accounts with multiple providers to take advantage of free cloud storage facilities offered by some cloud store providers. For instance, Amazon Cloud Drive offers 5 GB of free storage, SkyDrive offers 7 GB of free storage space, Google Drive offers 5 GB of free storage, etc. To access further storage beyond the free space offerings, some cloud store providers require users to subscribe to a paid service. For some would-be consumer-users, the free cloud storage space provided by a single provider may or may not constitute sufficient storage space, but aggregated free storage space from multiple cloud store providers together sometimes could possibly provide sufficient storage space. Unfortunately, however, the user cannot see these providers as integrated (or contiguous) storage. The user instead will need to deal with each provider separately, e.g., through the disparate interfaces (and APIs) offered by the different cloud store providers. Thus, the user not only has to deal with the peculiarities of the interfaces of the disparate cloud store providers, but also will not be able to access the storage space from different providers (for that same user) as a contiguous storage space.
In addition, it will be appreciated that regardless of whether the cloud stores are free or access on a for-pay basis, an end user might at least sometimes find it useful to be able to copy, move, and otherwise manage content between providers in a seamless fashion, while dealing with a single interface independent of a specific cloud store provider. Such functionality could be particularly valuable in scenarios where back-up, mirroring, and/or other operations, are concerned. As a specific example, a user might wish to set up automatic mirroring between two cloud store providers so that (i) it serves as a back-up for the user data in the cloud, (ii) in case of outage of one of the cloud store providers, the other mirror is available from a different cloud store provider, for the user to retrieve the data, etc. But this sort of data sharing is not easily accomplished using existing techniques and, as a result, a user cannot readily account for the scenarios of a provider outage, a provider losing the consumer data due a catastrophic event on the provider systems, etc., even if the provider is not totally inaccessible.
In this vein, an end user might find it useful in some cases to be able access integrated storage from multiple, disparate cloud store providers via disparate access methods such as, for example, from a mobile device (e.g., an iPhone or Android type device), a Tablet (e.g., an iPad, a tablet running the Android operating system, etc.), a laptop or desktop computer, etc. It would be desirable to be able to use interfaces that are similar or identical (and provide the same or similar usability experience) across all potential access devices, to the extent possible. As a simple example, a user might wish to authenticate with a single gateway but, unfortunately, users currently need to authenticate with each of the cloud drive providers each time of use, as no single sign-on like scenario is available. The requirement to install multiple software components to access the different providers can in some cases lead to incompatibilities or other conflicts and, at a minimum, may be seen as an annoyance in terms of user effort and processing resources required.
An end user also might find it useful to be able to add additional cloud store providers into, and remove unneeded and/or undesirable providers (and potentially also the associated accounts) from an integrated storage system on a dynamic basis. The latter could be from a user's desire or necessitated by a cloud store provider going out of existence (on a short notice).
Unfortunately, however, an end user currently needs to deal with “N” different providers, manage a separate account with each provider, and interact with each provider in its respective private ways. In addition, an end user oftentimes needs to install provider-specific software (e.g., drivers) and utilize device-specific interfaces with each provider, for each of the devices used.
FIG. 1 is a mesh that schematically shows device and provider specific user access to multiple, disparate cloud drive providers. FIG. 1 shows example devices 102a-102d, and example cloud providers 104a-104e. As can be seen from FIG. 1, and as alluded to above, a user will need to deal with different cloud drive providers using different provider specific interfaces and device specific access methods, each time the user needs to interact with the providers (in addition to using provider specific credentials and authentication mechanisms). As can also be appreciated from the FIG. 1 example and the description above, the user is also dealing with each provider in an isolated fashion, and there is no easy way move copy or transfer content from one provider to the other. In fact, the user does not even have an integrated view of all of the cloud content from the different providers.
It therefore will be appreciated that it would be desirable for a user to be able to interact with a single provider, or a system that mimics a single provider, that (for example) presents a more uniform interface (potentially irrespective of a specific cloud store provider), provides the ability to work seamlessly with all cloud store providers (e.g., when copying, moving, adding, removing, accessing, or otherwise managing content with respect to one or more specific cloud store providers), etc.
Perhaps more generally, it will be appreciated that there is a need in the art for techniques that facilitate uniform and integrated access to storage from disparate cloud drive providers.
In certain example embodiments, a Heterogeneous Cloud-Store Provider Access System (HCPAS), and associated methods, are provided.
An aspect of certain example embodiments relates to providing single sign-on server based access systems and/or methods, together with a common access API for managing storage across differing cloud storage systems spread over a distributed heterogeneous environment.
Another aspect of certain example embodiments thus relate to a server-side solution that manages multiple cloud store provider accounts on behalf a consumer. It may, for example, present a more uniform interface to the consumer, while dealing with different cloud store providers on behalf of the user, at the backend, using the cloud store provider specific APIs (such as, for example, the Apple iCloud API, the Amazon Cloud Drive API, the Dropbox API, the skydrive API, etc.).
Another aspect relates to using the HCPAS to manage the distributed storage and provide improved common access. Having a clear view of which files are deployed to which locations, and being able to easily transfer them from one cloud provider to another as part of managing the distributed cloud, is an advantageous feature of certain example embodiments.
In certain example embodiments, a heterogeneous cloud provider access system including a plurality of disparate cloud computing systems operated by different respective cloud providers is provided. A server comprises at least one processor. A configuration database stores a plurality of user records (potentially on a non-transitory computer readable storage medium), with each said user record indicating, for a respective user, which cloud providers the respective user has an account with and login information for each of these cloud providers. A plurality of end-user devices is provided, with each said device being connectable to the server via an application running thereon. For each of a plurality of operations requestable through an instance of the application, a mapping is defined between the respective operation and one or more provider-specific API calls associated with performance and/or execution of the respective operation, regardless of the type of the device running the instance of the application.
In certain example embodiments, a method of managing a heterogeneous cloud provider access system including a plurality of disparate cloud computing systems operated by different respective cloud providers is provided. The method comprises: storing a plurality of user records in a database, each said user record indicating, for a respective user, which cloud providers the respective user has an account with and login information for each of these cloud providers; enabling a plurality of end-user devices to connect to a server of the heterogeneous cloud provider access system via an application running on the devices, the server including at least one processor; and maintaining, for each of a plurality of operations requestable through an instance of the application, a mapping between the respective operation and one or more provider-specific methods associated with performance and/or execution of the respective operation.
In certain example embodiments, a server is connected to a heterogeneous cloud provider access system including a plurality of disparate cloud computing systems operated by different respective cloud providers. The server comprises processing resources including at least one processor. There is a connection to a database storing a plurality of user records, with each said user record indicating, for a respective user, which cloud providers the respective user has an account with and login information for each of these cloud providers. A connection pool is configured to enable a plurality of end-user devices to connect to the server via applications running on the respective devices. The processing resources are configured to at least access, for each of a plurality of operations requestable through an instance of the application, a mapping between the respective operation and one or more provider-specific application programming interface (API) calls associated with performance and/or execution of the respective operation, regardless of the type of the device running the instance of the application.
In certain example embodiments, a heterogeneous cloud provider access system including a plurality of disparate cloud computing systems operated by different respective cloud providers is provided. The heterogeneous cloud provider access system comprises a server. A configuration database is adapted for storing a plurality of user records, with each said user record indicating, for a respective user, which cloud providers the respective user has an account with and/or corresponding login information. A plurality of end-user devices is provided, with each said device being connectable to the server via an application running thereon. For each of a plurality of operations requestable through an instance of the application, a mapping is made between the respective operation and one or more provider-specific application programming interface (API) calls associated with performance of the respective operation, regardless of the type of the device running the instance of the application.
In certain example embodiments, a method of managing a heterogeneous cloud provider access system including a plurality of disparate cloud computing systems operated by different respective cloud providers is provided. A plurality of user records is stored in a database, with each said user record indicating, for a respective user, which cloud providers the respective user has an account with and/or corresponding login information. A plurality of end-user devices are enabled to connect to a server of the heterogeneous cloud provider access system via an application running on the devices. For each of a plurality of operations requestable through an instance of the application, a mapping between the respective operation and one or more provider-specific methods associated with performance of the respective operation is maintained.
In certain example embodiments, a server, adapted for being connected to a heterogeneous cloud provider access system including a plurality of disparate cloud computing systems operated by different respective cloud providers, is provided. The server includes a connection to a database adapted for storing a plurality of user records, with each said user record indicating, for a respective user, which cloud providers the respective user has an account with and/or corresponding login information. Means for enabling a plurality of end-user devices to connect to the server via applications running on the respective devices are provided. The server is adapted to at least access, for each of a plurality of operations requestable through an instance of the application, a mapping between the respective operation and one or more provider-specific application programming interface (API) calls associated with performance of the respective operation, regardless of the type of the device running the instance of the application.
Non-transitory computer readable storage mediums tangibly storing instructions for performing the above-summarized and/or other methods also are provided by certain example embodiments, as well as corresponding computer programs.
According to certain example embodiments, the server is configured to, in cooperation with its at least one processor: receive a request for an operation to be performed and/or executed with respect to one or more cloud computing systems, determine which cloud computing system(s) is/are associated with the request, identify one or more mappings needed to perform and/or execute the request based on the determination, and make any necessary API calls to the cloud computing system(s) that is/are associated with the request, in accordance with the identified one or more mappings. In other words, according to certain example embodiments, one or more provider-specific methods are caused to be performed and/or executed in connection with the cloud computing system(s) that is/are associated with the request, in accordance with the identified one or more mappings.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.